The present invention relates generally to object-oriented computer programming, and, more particularly, to methods and systems for designing containers for use in compound document applications.
Compound document technology, such as Microsoft""s Object Linking and Embedding (xe2x80x9cOLExe2x80x9d), is notoriously difficult to develop and utilize. A compound document is an application environment containing program objects that can be interlinked and interacted with by a user. For example, FIG. 1 sets forth an OLE container application 110, such as a word processor (e.g. Microsoft Word) or web browser (e.g. Microsoft Internet Explorer), which can contain objects 150 imported from other applications. The components are integrated using Microsoft""s proprietary framework known as the Component Object Model or COM. COM and OLE (or its current incarnation known as ActiveX) originated as an inter-client cut-and-paste protocol, but have grown to include many advanced services, including object naming, in-place editing, canvas event management (e.g. resize, drag-and-drop), toolbar and menu sharing, and loading and saving of persistent state.
OLE/ActiveX provides support for what it calls automation services which allow components to be controlled through public COM interfaces. An automation object (a/k/a xe2x80x9cserverxe2x80x9d) implements and publishes interfaces; an automation controller (a/k/a xe2x80x9cautomatorxe2x80x9d or xe2x80x9cclientxe2x80x9d) calls methods in these interfaces. ActiveX also supports more sophisticated components called ActiveX controls (a/k/a OCXs or OLE Custom Controls) which are editable embedded objects that can also transform user actions into notification events sent to the container. Standard development tools have simplified the design of contained objects such as ActiveX controls. In 1996, Microsoft drafted a new specification called OCX96 which, inter alia, provided support for windowless, non-rectangular and transparent controls.
On the other hand, the process of creating a new container application fully supporting such objects remains difficult at best, complicated by the feature-rich nature of ActiveX. OLE does not provide a standard container implementation; rather it is more accurately described as a contract between applications. As illustrated by FIG. 1, a container application must provide support for a multiplicity of interfaces (e.g. to support linking, drag-and-drop, data transfer) in order to handle a wide range of components. The hierarchical model of the OLE architecture complicates matters: there is no support in the persistence and naming scheme for connections between objects in a system without one object owning the other or another owning both. Moreover, OLE allows only one active object to negotiate with the container for toolbar and menu space. The protocol simply does not include support for many of the issues that arise when a system is composed of heterogeneous components.
Although some of the complexity of programming in OLE can be encapsulated using a class library such as Microsoft Foundation Classes (MFC), support is not provided for all of the functions that are in the raw OLE APIxe2x80x94especially newer features such as windowless controls. Accordingly, a new container-object architecture is needed that reduces the development time required for creating a general container application and which does not rely on large external libraries.
The present invention discloses a convenient framework for container applications. A customizable embeddable container is provided, and client objects of the container may be positioned dynamically by an external layout agent. The container manages toolbars and user interface modes, integrating disparate components into a single consistent interface. Group repositories of related objects for data transfer operations such as cut-and-paste, drag-and-drop, save-and-load, can be supported. The present invention advantageously does not rely on large external libraries and, thus, is relatively lightweight.
The accordance with an embodiment of the present invention, the GUI is separated from the dynamic layout engine. A generic user interface component is provided for creating nested applications/components. A protocol for user interface xe2x80x9cmodesxe2x80x9d is disclosed, as well as object repositories that support the common data transfer operations (load, save, cut, paste, drag, drop) while preserving links between the objects; hooks for dynamic object layout; menu sharing between active objects through simple call-outs and data structures; and toolbar management through a shared container object that represents the toolbar area. Unlike a typical application container, all document semantics have been factored out. In addition, the present invention permits far more convenient support for toolbars and data transfer.